home *** CD-ROM | disk | FTP | other *** search
- Path: engnews2.Eng.Sun.COM!taumet!clamage
- From: vandevod@cs.rpi.edu (David Vandevoorde)
- Newsgroups: comp.std.c++
- Subject: Re: Observations on templates
- Date: 29 Jan 1996 19:15:51 GMT
- Organization: RPI Computer Science
- Sender: vandevod@avs.cs.rpi.edu
- Approved: clamage@eng.sun.com (comp.std.c++)
- Message-ID: <xso7mya95x9.fsf@avs.cs.rpi.edu>
- References: <ACVI83na99@qsar.chem.msu.su>
- NNTP-Posting-Host: taumet.eng.sun.com
- Content-Type: text
- X-Nntp-Posting-Host: avs.cs.rpi.edu
- In-Reply-To: "Eugene Radchenko"'s message of 29 Jan 96 10:38:37 GMT
- X-Newsreader: Gnus v5.1
- Content-Length: 3025
- X-Lines: 72
- Originator: clamage@taumet
-
- >>>>> "E" == "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:
- [...]
- E> 1) Clause [temp.res] verse 1 requires that all types dependent on the
- E> template parameter must be qualified by 'typename' keyword - supposedly to
- E> allow checking the template syntax. But it does not help anything as _each_
- E> instance will have to be checked anyway:
- [...]
-
- I don't think that `typename' was introduced with the intention of avoiding
- instantiation checks. I expect at least one of the goals was to permit the
- development of more refined tools (e.g., for the analysis of generic as
- opposed to instantiated code).
-
- E> 2) Clause [temp.dep] verse 5 states that base class scope names hide the
- E> template parameter:
- [...]
-
- Although I didn't check the issue, I would tend to agree with you here.
- In particular, consider:
-
- template<typename B>
- struct D: public B {
- // Cannot guarantee that a member of B won't hide the
- // classname itself.
- }
-
- Again, I didn't check this (i.e., what I say above may be unfounded).
-
- E> 3) Clause [temp.arg.explicit] verses 2-3 requires that for explicit arg in
- E> member template to be present it must be qualified by 'template' keyword,
- E> e.g.
- E> X *p; p->template alloc<200>();
- E> But to use operator -> we need X class definition anyway - so we know that
- E> alloc() is a template. Thus this keyword is redundant and likely to be
- E> forgotten (if I am not mistaken, it is in fact missing from some examples
- E> in lib.locale section).
-
- Same as 1).
-
- E> 4) Clause [temp.deduct] verse 4. Why the conversions other than Derived* ->
- E> Base* are not allowed in template deduction (at least default conversions
- E> like char->int; user conversions would be even better)?
-
- I suppose this is a matter of avoiding complexity. Remember that the more
- possibilities the compiler must consider, the more time it will take to
- compile this code (and in this case we're talking about superlinear
- growth). From a maintainability point of view, implicit conversion can
- also be a hassle.
-
- [...]
- E> PS. Am I the only one who does not like the current drift in the C++ syntax
- E> from symbolic (C-like)
- E> int a[10];
- E> to verbose (Pascal-like)
- E> var
- E> a: array[0..9] of integer;
- E> way of expressing things? Why don't use, for instance, cast_d instead od
- E> dynamic_cast (ugh). Yeah, I know we are not using 10-cps terminals Richie
- E> (sp?) did, but anyway... (and it consumes compiler memory space :-)
- [...]
-
- I think that what you're observing is the tendency to require (or encourage)
- us to ``say what we mean''. The new casting syntax, the ban on implicit int,
- the explicit keyword, the uses of `typename' and `template' syntax that you
- mention and even the bool type are all ways to make more explicit in the
- source code what is going on. Considering the things that already happen
- automatically in C++ (virtual dispatch, template instantiation, destruction,
- user-defined conversions, ...), I am rather happy that those things that do
- not require transparency are made explicit.
-
- Daveed
-
-
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
- is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
-
-